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REMARKS/ARGUMENTS 

1. Election/Restriction Requirement . 

In the Official Action, claims 1-28, 35-39, and 47-51 were withdrawn from further 
consideration pursuant to the Election/Restriction Requirement. The applicants argued that 
claims to be restricted to different species should be mutually exclusive, applicants should not be 
precluded from electing their preferred embodiment upon which all of the claims are readable, 
and there has been no indication that there would be serious burden to search and examine all of 
the claims together in the application. The Official Action acknowledged that applicants' 
election was with traverse, but did not make the requirement final. The prosecution history of 
the present application, as posted on Public Pair, now contains search notes indicating that Class 
707 Subclasses 10, 203, and 205 were searched, and an EAST search history, pages 1 to 12, and 
Web results of Google searches, 8 pages, show a diligent search of various limitations in 
applicants' claims. 

It is respectfully submitted that there has been no prima facie showing of "a serious 
burden on the Examiner" by appropriate explanation of separate classification, or separate status 
in the art, or a different field of search. (Note M.P.E.P. 808.02: "Where, however, the 
classification is the same and the field of search is the same and there is no clear indication of 
separate future classification and field of search, no reasons exist for dividing among 
independent or related inventions.") Moreover, it is not understood how the search notes and 
EAST search history would support a showing of such a serious burden. 
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The Examiner is respectfully requested to reconsider the restriction requirement, and if 
the restriction requirement is to be maintained, the Examiner is respectfully requested to make 
the requirement final pursuant to M.P.E.P. 803.01 and 821.01. 

2. Claim Rejections -35 U.S.C. 1 12 . 

Claims 29, 30, 40, 42, and 52 were rejected under 35 U.S.C. 1 12, second paragraph for 
failing to clearly delimit the preamble and the claim limitations. In response, these claims have 
been amended by inserting additional punctuation to clearly delimit the preamble and the claim 
limitations. In addition, all of the claims have been reviewed and amended where appropriate for 
consistency. Claims 2, 5, 6, 7, 13, 15, 27, 40, and 52 have been amended to replace "node" or 
"nodes" with -inode- or -inodes- for more clear antecedent basis. Claims 44, 45, and 46 have 
been amended for consistent use of the antecedent terminology. 

3. Claim Rejections - 35 U.S.C. 103 . 

Claims 29-34, 40-46, and 52-53 were rejected as unpatentable under 35 U.S.C. 103(a) as 
being obvious over U.S. Patent No. 6,434,681 issued to Armangau in view of U.S. Patent No. 
6,892,21 1 issued to Hitz et al. Applicants respectfully traverse. 

The applicants' invention of claim 29 is directed to a file server having a snapshot copy 
facility that maintains a file system including a production file, read-only snapshot copies of the 
production file, and at least one read-write snapshot copy of the production file. The production 
file and the snapshot copies of the production file are organized as a version set. The version set 
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includes an inode for the production file and an inode for each snapshot copy of the production 
file, and a set of file blocks including data blocks and indirect blocks that are shared among the 
production file and the snapshot copies of the production file. See, for example, applicants' 
FIGS. 15 and 16 which show inodes sharing data bocks and indirect blocks, and FIGS. 19 and 23 
which show a version set including read-only snapshot version inodes and read-write snapshot 
branch inodes, and FIG. 24, which shows the creation of a read-only version of the production 
file, and FIG. 25, which shows the creation of a read-write branch off a read-only base version. 
(Applicants' specification, page 32 lines 5-22, page 40 line 1 1 to page 42 line 12, page 46 lines 
12-21, page 50 line 3 to page 51 line 5.) 

Armangau 6,434,681 does not disclose sharing of data blocks and indirect blocks among 
a production file and snapshot copies of the production file in a file system. Instead, the 
snapshot copy facility of Armangau 6,434,681 creates and backs up a snapshot copy of a 
specified extent of a production volume, and may restore the extent of the production volume 
with the snapshot copy. As shown in FIG. 7B of Armangau, when writing to a track in an extent 
of a snapshot, if the track has not been modified, the "before image" of the track is copied from 
the production volume to a snapshot volume track (step 126) before writing new data to the track 
in the production volume (step 129). As shown in FIG. 8 A or 8C of Armangau, unmodified 
tracks of the production volume extent are copied from the production volume to secondary 
storage (step 133 or 245), and the before images of the modified tracks are copied from the 
snapshot volume to the secondary storage (step 137 or 244). FIG. 9 of Armangau shows a 
format of a data record on the backup tape. This data record includes, after an inter-record gap, a 
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synchronization code 142, a record number 143, a version ID 144, a track no. 145, track data 
146, and finally an error correction code 147 preceding another inter-record gap 148. The 
records on the backup tape are not necessarily sequential by track number. (Armangau, col. 18, 
lines 18-25.) 

When data blocks and indirect blocks are shared among a production file and snapshot 
copies of the production file in a file system, the snapshot copies become read-only unless, as 
taught by applicants, a means is provided for unsharing blocks of a snapshot copy when writing 
data to the snapshot copy. 

For example, the snapshot copy facility of Hitz et al. shares data blocks and indirect 
blocks between the production file and a newly created snapshot copy of the production file 
when the inode of the production file is duplicated. Hitz et al. recognize that this "creates 
snapshots that are read-only copies of the file system." (Hitz et al., Abstract; emphasis added; 
see also Hitz FIG. 18B and col. 18 lines 41-65; col. 23 lines 57-59.) However, Hitz et al. fails to 
disclose or suggest making such snapshot file copies have a read-write capability in the file 
system. 

The applicants' claim 29 is a "means plus function" claim. Pursuant to 35 U.S.C. 1 12 
paragraph 6, "such claim shall be construed to cover the corresponding structure, material, or 
acts described in the specification and equivalents thereof." In re Donaldson 16 F.3d 1 189, 1 194, 
29 U.S.P.Q. 2d 1845, 1850 (Fed. Cir. 1994)(the PTO may not disregard the structure disclosed in 
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the specification corresponding to a "means or step plus function" limitation in accordance with 35 
U.S.C. § 112, 6th paragraph); see also In re Bond . 910 F.2d 831, 833, 1568, 15 U.S.P.Q.2d 1566 
(Fed. Cir. 1990). 

The applicants' "means for creating new read-only snapshot copies of the production 
file" are shown in applicants' FIG. 24, as described in applicants' specification on page 50 lines 
3-15. The applicants' "means for creating new read-write snapshot copies of the production 
file" are shown in applicants' FIG. 25, as described in applicants' specification on page 50 line 
16 to page 51 line 5. The applicants' "means for deleting a specified snapshot copy of the 
production file from the version set" are shown in appellants' FIG. 26, as described in 
applicants' specification on page 51 line 6 to page 53 line 20. The appellants' "means for 
restoring the production file with a specified snapshot copy of the production file" are shown in 
appellants' FIG. 29-32; as described in appellants' specification on page 56 line 4 to page 58 line 
10. The appellants' "means for refreshing a specified snapshot copy of the production file" are 
shown in appellants' FIG. 33, as described in appellants' specification on page 58 line 11 to 22. 
Appellants' "means for naming the files in the version set" are shown in applicants' FIGS. 34- 
35, as described in appellants' specification on page 59 line 1 to page 61 line 21. 

Armangau 6,434,681 does not disclose the various operations performed by applicants' 
claimed means upon inodes because Armangau does not disclose sharing of data blocks and 
indirect blocks among a production file and snapshot copies of the production file in a file 
system. Nor does Armangau disclose that the restore includes a prepare restore operation and a 
commit restore operation. Nor does Armangau disclose a means for naming files in a version 
set. 
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The applicants' means defined in claim 29 also have a structure and operation 
substantially different from Hitz et al. because Hitz et al. does not perform operations upon a 
read-write snapshot file in the file system. In particular, the applicants' means provide a 
mechanism for read-write snapshots to share data blocks and indirect blocks among a production 
file and snapshot copies by linking branch inodes upon base inodes that are inodes of read-only 
snapshot copies in a version chain. Thus, Hitz et al. does not disclose or suggest the applicants' 
means of FIG. 25 for creating a read- write branch snapshot inode off a read-only base snapshot 
inode, nor a restoration mechanism including a prepare restore involving the creation of a new 
branch file copy from a specified base version or a commit restore in which the new branch file 
assumes the identity of the production file, nor a means for naming the files in the version set 
including a way of distinguishing read-write branch snapshots from read-only version snapshots 
and in particular identifying the read-only version upon which a branch snapshot is based. 

The applicants' claims 30-34 and 42-44 deal with a problem that arises because file 
blocks including data blocks and indirect block s are shared among a production file and read- 
only snapshot copies of the production file. This problem is whether or not to keep blocks of a 
read-only snapshot copy when the read-only snapshot copy is deleted. This problem is solved by 
programming the file server to maintain for each block in each snapshot copy of the production 
file an indication of whether or not said each snapshot copy of the production file is an oldest 
snapshot copy of the production file including an identical version of each block. As set out in 
claims 30 and 42, when deleting the read-only snapshot copy of the production file, the file 
server keeps each block for which the read-only snapshot copy is not indicated as being an oldest 
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snapshot copy of the production file including an identical version of said each block. For 
example, as shown in applicants' FIG. 22, the indication is a non-owner flag 196, 197 associated 
with each data block pointer 194 or indirect block pointer 195 in the modified inode 190. 
(Applicants' specification, page 44 line 17 to page 45 line 14.) As shown in FIG. 26, step 243, 
for the first entry in the action table, if the block in the version being deleted is not owned by that 
version, then that block is ignored so it is not deleted. (Applicants' specification, page 52, lines 
12-16.) 

Applicants' dependent claims 3 1 and 43 further define that the deleting of the read-only 
snapshot copy of the production file includes keeping all descendants of said each block for 
which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block. Also with respect to 
Applicants' FIG. 26, step 243, for the first entry in the action table, by inheritance, all of the 
descendants of the block in the block hierarchy are shared with and owned by an earlier snapshot 
copy, so they also are ignored so they are not deleted. (See applicants' specification, page 52, 
lines 16-19.) 

Applicants' dependent claims 32 and 44 further define that the deleting of the read-only 
snapshot copy of the production file includes keeping each block for which the read-only 
snapshot copy of the production file is indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block and a next-most recent snapshot 
copy of the production file is indicated as not being an oldest snapshot copy of the production 
file including an identical version of said each block. This is shown in applicants' FIG. 26, step 
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243, in the second entry in the action table, as described in applicants' specification, page 52 line 
20 to page 53 line 5. 

Applicants' dependent claims 33 and 45 further define, upon deleting the read-only 
snapshot copy of the production file, indicating that the next-most recent snapshot copy of the 
production file has become an oldest snapshot copy of the production file including an identical 
version of said each block for which the read-only snapshot copy of the production file is 
indicated as being an oldest snapshot copy of the production file including an identical version of 
said each block and a next-most recent snapshot copy of the production file is indicated as not 
being an oldest snapshot copy of the production file including an identical version of said each 
block. This is also shown in applicants' FIG. 26, step 243, in the second entry in the action table 
("Pass block to next"), as described in applicants' specification, page 52 line 20 to page 53 line 
5. 

Applicants' dependent claims 34 and 46 further define that the deleting of the read-only 
snapshot copy of the production file includes deallocating each block for which the read-only 
snapshot copy of the production file is indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block and a next most recent snapshot 
copy of the production file is also indicated as being an oldest snapshot copy of the production 
file including an identical version of a block corresponding to said each block, wherein said each 
block and the block corresponding to said each block are mapped to the same logical file 
addresses. This is also shown in applicants' FIG. 26, step 243, in the third entry in the action 
table, as described in applicants' specification, page 53 lines 11-18. 
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With respect to claims 30-34 and 42-46, the Official Action recognizes that Armangau 
does not expressly disclose an oldest snapshot copy, or when deleting a snapshot copy, to keep 
each block for which a snapshot copy is not indicated as being an oldest snapshot copy. The 
Official Action cites Hitz et al. col. 21, lines 49-50; col. 23, lines 28-55; col. 21, lines 49-50; and 
col. 23, lines 28-55. However, Hitz et al. does not "maintain for each block in each snapshot 
copy of the production file an indication of whether or not said each snapshot copy of the 
production file is an oldest snapshot copy of the production file including an identical version of 
said each block." Instead, for re-allocation of blocks of a deleted snapshot, Hitz et al. maintains 
a multi-bit free block map. A first bit in the multi-bit free block map indicates whether a block is 
used by the active file system, and 20 remaining bits are used for up to 20 snapshots. (Hitz col. 
4, lines 40-45.) All snapshot bits are initially set to zero. If the active file bit is cleared before 
any snapshot bits are set, the block is not present in any snapshot stored on disk. Therefore, the 
block is immediately available for reallocation and cannot be recovered subsequently from a 
snapshot. (Hitz col. 22, lines 1-6.) When a new snapshot is created, the entries in the blockmap 
are updated by copying the FS-bit into the snapshot bit. (Hitz, FIG. 7, step 760, and FIG. 17D.) 

Where the prior art references fail to teach a claim limitation, there must be "concrete 
evidence" in the record to support an obviousness rejection. "Basic knowledge" or "common 
sense" is insufficient. In re Zurko . 258 F.3d 1379, 1385-86, 59 U.S.P.Q.2d 1693, 1697 (Fed. Cir. 
2001). 
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The applicants' claims 40 and 52 call for refreshing a specified snapshot copy of the 
production file, and not restoring the production file with a snapshot version. The refreshing of 
applicants' claims 40 and 52 includes four distinct operations; namely, "creating a new inode in 
the version set, copying contents of the inode of the specified snapshot copy into the new inode 
so that the new inode references blocks of the specified snapshot copy, using the inode of the 
specified snapshot copy to create a new snapshot copy of the production file by copying contents 
of the inode of the production file into the inode of the specified snapshot copy, and performing a 
file deletion upon the new inode." This is shown in applicants' FIG. 33, steps 301 to 304, as 
described in applicants' specification, page 58 lines 11-22, 

With respect to claims 40-41 and 52-53, the applicants' refreshing method does not result 
by using the snapshot copy facility of Armangau to copy a volume extent containing a file 
having an inode. Instead, Armangau e.g. col. 8 lines 47-49 describes copying a version of 
backup data identified by a tag from the secondary storage 39 to the primary storage 29 so that 
the version of the backup data identified by the tag becomes the current version in the primary 
storage. Thus, whatever was in the volume extent at the time of the snapshot will be put back as 
it was in primary storage. Therefore, it is not understood how the applicants' four distinct 
operations for a refresh are suggested by the restoration technique of Armangau in view of the 
teaching of up to 20 snapshot copy inodes in Hitz (col. 18, lines 1-18). 

Hindsight reconstruction, using the applicants' specification itself as a guide, is improper 
because it fails to consider the subject matter of the invention "as a whole" and fails to consider the 
invention as of the date at which the invention was made. "[T]here must be some motivation, 
suggestion, or teaching of the desirability of making the specific combination that was made by 
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the applicant." In re Lee . 277 F.3d 1338, 1343, 61 U.S.P.Q.2d 1430, 1435 (Fed. Cir. 2002). )). 
"[Particular findings must be made as to the reason the skilled artisan, with no knowledge of the 
claimed invention, would have selected these components for combination in the manner 
claimed." In re Kotzab . 217 F.3d 1365, 1371, 55 U.S.P.Q.2d 1313, 1317 (Fed. Cir. 2000). See, 
for example, Fromson v. Advance Offset Plate. Inc. . 755 F.2d 1549, 1556, 225 U.S.P.Q. 26, 31 
(Fed. Cir. 1985) (nothing of record plainly indicated that it would have been obvious to combine 
previously separate lithography steps into one process); In re Gordon et al. . 733 F.2d 900, 902, 221 
U.S.P.Q. 1 125, 1 127 (Fed. Cir. 1984) (mere fact that prior art could be modified by turning 
apparatus upside down does not make modification obvious unless prior art suggests desirability of 
modification); Ex Parte Kaiser . 194 U.S.P.Q. 47, 48 (PTO Bd. of Appeals 1975) (Examiner's failure 
to indicate anywhere in the record his reason for finding alteration of reference to be obvious 
militates against rejection). 

Applicants' dependent claims 41 and 53 further define that the file deletion upon the new 
inode is performed asynchronously after using the inode of the specified snapshot copy to create a 
new snapshot copy of the production file by copying contents of the inode of the production file in 
to the specified snapshot copy. This is shown in applicants' FIG. 33, steps 303-304, as described in 
applicants' specification, page 58, lines 16-22. 

With respect to the dependent claims 41 and 53, the Official Action cites Armangau col. 20, 
lines 55-67 and Hitz col. 18, lines 1-16. Armangau col. 20 lines 55-57 relates to a procedure of FIG. 
16 invoked when a data mover receives a backup request from a primary data storage subsystem. 
Hitz col. 18 lines 1-16 relates to the WAFL system supporting up to 20 different snapshots each 
represented by a snapshot inode. It is not understood how these passages disclose or suggest the 
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limitations of applicants' claims 41 and 53, which specify that file deletion upon the new inode is 
performed asynchronously after using the inode of the specified snapshot copy to create a new 
snapshot copy of the production file. 

In view of the above, it is respectfully submitted that the application is in condition for 
allowance. Reconsideration is respectfully requested, and early allowance is earnestly solicited. 



Respectfully submitted, 



Richard C. Auchterlonie 
Reg. No. 30,607 

NOVAK DRUCE & QUIGG, LLP 
1000 Louisiana, 53 rd Floor 
Houston, TX 77002 
713-571-3460 
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